cw(24p) | lw(36p) | cw(24p) | cw(18p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) | cw(12p) | cw(18p) | cw(12p) , ^ | l | l | l | l | l | l | l | l | l | l
^ | l | l | l | l | l | l | l | l | l | l.
{
Messages per call
12\(hydigit IAM
\ 6\(hydigit IAM
\ 3\(hydigit SAM
\ 1\(hydigit SAM
Length
(bits)
176
152
128
112
1 |
1
1
0
1 |
1 |
3 |
1
1
3
1
0
0
1
1
0
Address complete
112
1 |
1
0
0
1 |
1
0
0
} Others 112 3,5 2 3 0 3,5 2 3 2
.TE
.LP
AW
Answered
SB
Subscriber busy and not answered
CC
Circuit congestion
AB
Abortive
.LP
\fINote\ \(em\ \fR
The assumptions used in this model are chosen for illustrative
purposes, and should not be considered to be typical.
\fIGeneral description of user\(hyto\(hyuser service\fR
.sp 9p
.RT
.PP
The user\(hyto\(hyuser signalling supplementary service(s) provide(s) a
means of communication between two users by using the ISDN User Part or
SCCP
protocols defined in Recommendations Q.711\(hy714 and Q.761\(hy764, 766.
In order for the services to be usable, they also have to be provided in
the access
protocol.
.PP
User\(hyto\(hyuser signalling is used to exchange I.257 information between
two users to provide the user\(hyto\(hyuser services described in Recommendation
I.257. This section is specific to Signalling System\ No.\ 7. The general
description for services\ 1\(hy3 may be found in the last mentioned Recommendation
and the functional description in Recommendation\ Q.87.
.RT
.sp 1P
.LP
2.1.1
\fIUser\(hyto\(hyuser services\fR
.sp 9p
.RT
.PP
Three user\(hyto\(hyuser signalling services
associated with circuit\(hyswitched
calls that may be provided by the network users
are:
.RT
.LP
\fIService\ 1:\fR \ user\(hyto\(hyuser signalling exchanged during the
set\(hyup and clearing phases of a call, within ISDN User Part call set\(hyup
and
release messages as defined in Recommendation\ Q.763;
.LP
\fIService\ 2:\fR \ user\(hyto\(hyuser signalling exchanged during call
set\(hyup between the address complete or call progress messages and the
answer or connect messages, within user\(hyto\(hyuser information messages;
and
.LP
\fIService\ 3:\fR \ user\(hyto\(hyuser signalling exchanged while a call is
in the active state, within user\(hyto\(hyuser information messages.
.PP
All three services may be used separately or in any combination
within a single call. As an option at call set\(hyup, users may be able
to specify whether the requested user\(hyto\(hyuser signalling service(s)
is(are) essential or non\(hyessential for the call (i.e. whether the call
should be completed or not if user\(hyto\(hyuser information cannot be
passed). Up to 128\ octets of user
information may be transferred in a message in each of the three
services
.FS
During an interim period of time, networks may support a lesser
number (e.g.\ 32\ octets) due to protocol restrictions; 32\ octets will
always be supported. Restrictions may apply to calls requesting user\(hyto\(hyuser
information more than 32\ octets.
.FE
. The 128\ octets does not include the user\(hyto\(hyuser
information parameter name, the protocol control indicator or the length
octets.
.sp 1P
.LP
2.1.2
\fIService request\fR
.sp 9p
.RT
.PP
Service 1 may be requested implicitly by the presence of the
user\(hyto\(hyuser information parameter in the Initial Address Message.
An implicit request is \*Qnon\(hyessential\*U by default.
.PP
Explicit requests of Service 1 and 2 must be in the Initial Address
Message. Service 3 may be explicitly requested in the Initial Address Message
during call set\(hyup. When there is an explicit request a single user\(hyto\(hyuser
indicators parameter will be used with one of the following indications for
each of the three services:
.RT
.LP
\(em
no information;
.LP
\(em
requested, non\(hyessential;
.LP
\(em
requested, essential.
.sp 1P
.LP
2.1.3
\fIResponse (Confirmation)\fR
.sp 9p
.RT
.PP
If explicit requests are used there should, in general, be explicit responses
in a user\(hyto\(hyuser indicators parameter with one of the following
indications for each of the three services:
.RT
.LP
\(em
no information;
.LP
\(em
provided;
.LP
\(em
not provided.
.bp
.PP
Implicit \*Qnot provided\*U responses occur when:
.LP
\(em
Service 1 has been implicitly requested and no user\(hyto\(hyuser information
is received in call set\(hyup or release messages; or
.LP
\(em
Service 1, 2 or 3 has been explicitly requested and there is no indication
of acceptance or rejection from call control.
.sp 1P
.LP
2.1.4
\fIFlow control\fR
.sp 9p
.RT
.PP
The exchange of user\(hyto\(hyuser signalling is limited by flow control
procedures provided on the access by either the user or network. The need
for interexchange flow control procedures by the ISDN User Part for user\(hyto\(hyuser
signalling should be evaluated.
.RT
.sp 1P
.LP
2.2
\fIProcedures for user\(hyto\(hyuser signalling associated with\fR
\fIcircuit\(hyswitched call\fR
.sp 9p
.RT
.PP
The following sections only specify the signalling procedure used to implicitly
invoke the Service\ 1. Signalling procedures defined to support
the other services are specified in Annex\ A.
.RT
.sp 2P
.LP
2.2.1
\fIUser\(hyto\(hyuser signalling, Service 1\fR
.sp 1P
.RT
.sp 1P
.LP
2.2.1.1
\fIGeneral characteristics\fR
.sp 9p
.RT
.PP
Service 1 allows users to communicate with user\(hyto\(hyuser signalling
by transferring user\(hyto\(hyuser information within ISDN User Part messages
during the call set\(hyup and clearing phases. The user\(hyto\(hyuser signalling
service
provided is not a guaranteed service. If for any reason the combination
of the basic plus supplementary service information causes the overall
maximum length of the message to be exceeded then if the User\(hyto\(hyuser
Signalling Service\ 1 is included, then the service should be rejected.
.RT
.sp 1P
.LP
2.2.1.2
\fIUser\(hyto\(hyuser signalling in the call set\(hyup phase \(em implicit\fR
\fIservice request\fR
.sp 9p
.RT
.PP
Procedures for call set\(hyup are as described in Recommendation
Q.764, \(sc\ 2, with the following changes:
.PP
Service 1 may be invoked by sending the user\(hyto\(hyuser information
parameter of variable length that is specified in Recommendation\ Q.763,
\(sc\ 3.34 in an Initial Address Message that is requested in a call set\(hyup
request from call control. This information parameter is transported across
the network and delivered unchanged to the terminating call control for
the called user. The
user\(hyto\(hyuser indicators parameter will not be sent.
.PP
The reception of a user\(hyto\(hyuser information parameter in a call set\(hyup
or release request from the terminating call control is an implicit indication
of the acceptance of Service\ 1.
.PP
The user or network may not be able to interpret incoming user\(hyto\(hyuser
information. In such situations, the user should discard this information
without disrupting normal call handling. No specific signalling is provided
by the network to accommodate this situation.
.RT
.sp 1P
.LP
2.2.1.3
\fIInterworking\fR
.sp 9p
.RT
.PP
In the case of interworking with a non\(hyISDN network, the
\*Qinterworking\*U protocol control information will be returned to the
originating exchange in the first appropriate message, e.g.\ an Address
Complete Message.
Two ISDN networks that interwork may have to retain knowledge of the service
request until it is clear whether both can support the service.
.RT
.sp 1P
.LP
2.2.1.4
\fIRejection of implicit service requests\fR
.sp 9p
.RT
.PP
Networks that cannot provide the service requested may not return a rejection
indication.
.RT
.sp 1P
.LP
2.2.1.5
\fIUser\(hyto\(hyuser signalling in the call clearing phase\fR
.sp 9p
.RT
.PP
A user\(hyto\(hyuser information parameter may be included in the Release
Message. The user\(hyto\(hyuser information parameter received at the distant
exchange in the Release Message is passed to the call control for the remote
user. In the case of simultaneous clearing of the call, the Release Message
may not reach the distant local exchange and the user\(hyto\(hyuser information
will be lost.
.bp
.RT
.sp 1P
.LP
2.2.1.6
\fIMessage flow diagrams\fR
.sp 9p
.RT
.PP
The message flow diagrams are shown in Figure 1B/FQ.730 as well as
the use of user\(hyto\(hyuser signalling service\ 1 when implicitly requested
in a
point\(hyto\(hypoint configuration.
.PP
The messages shown with dashed lines are not part of the ISDN User
Part protocol and are for information only. For detailed information on the
access protocol user\(hyto\(hyuser procedures the ISDN access protocol
Recommendation should be examined.
.RT
.LP
.rs
.sp 48P
.ad r
\fBFigure 1/Q.730, p. 44\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.LP
\fB
.sp 2P
.LP
2.2.2
\fIInteraction with other supplementary services\fR
.sp 1P
.RT
.sp 1P
.LP
2.2.2.1
\fICall forwarding services\fR
.sp 9p
.RT
.PP
Interactions with the call forwarding services are shown in the
call forwarding protocol sections.
.RT
.sp 1P
.LP
2.2.2.2
\fICall waiting service\fR
.sp 9p
.RT
.PP
Interactions with the call waiting service are shown in the call
waiting protocol sections. (Call waiting is for further study.)
.RT
.sp 1P
.LP
2.2.2.3
\fIOther services\fR
.sp 9p
.RT
.PP
There are no known interactions with services other than those
listed.
.RT
.sp 1P
.LP
2.2.2.4
\fIState transition diagrams\fR
.sp 9p
.RT
.PP
The state transition diagrams may be found in Stage 2 descriptions of the
user\(hyto\(hyuser service.
.RT
.sp 2P
.LP
\fB3\fR \fBClosed user group (CUG)\fR
.sp 1P
.RT
.sp 1P
.LP
3.1
\fIGeneral\fR
.sp 9p
.RT
.PP
The closed user group (CUG) supplementary service enables a group of users
to intercommunicate only among themselves or, as required, one or more
users may be provided with incoming/outgoing access to users outside the
group.
.PP
The stage I definition of the CUG service is given in
Recommendation\ I.255, and its stage\ II service definition including network
functions are given in Recommendation\ Q.85.
.PP
The realization of the CUG facilities is done by the provision of
interlock codes and is based on various validation checks as defined in
Q.85 at call set\(hyup, determining whether or not a requested call to
or from a user
having a CUG facility is allowed. In particular, a validation check is
performed by verifying that both the calling and called parties belong
to the CUG indicated by the interlock code.
.PP
The data for each CUG that a user belongs to can either be stored at the
local exchange to which the user is connected (decentralized administration
of CUG data), or at dedicated point(s) in the network (centralized
administration of CUG data).
.PP
In \(sc\ 3.2 the call set\(hyup procedure based on decentralized
administration of CUG data is specified making use of the ISDN User Part as
defined in Recommendations\ Q.761\(hy764 and Q.766.
.PP
In \(sc\ 3.3 the call set\(hyup procedure based on centralized administration
of CUG data is specified making use of the ISDN User Part as defined in
Recommendations\ Q.761\(hy764 and Q.766 and the Transaction Capabilities
Application Part (TCAP) as defined in Recommendations\ Q.771\(hy775.
.PP
Section 3.4 specifies the application service element (ASE), situated above
the Transaction Capabilities Application Part (TCAP), and used for CUG
validation check with centralized administration of CUG data.
.RT
.sp 2P
.LP
3.2
\fICall set\(hyup procedure with decentralized administration\fR
\fIof CUG data\fR
.sp 1P
.RT
.sp 1P
.LP
3.2.1
\fIOriginating exchange\fR
.sp 9p
.RT
.PP
The actions at the originating exchange at call set\(hyup from a user belonging
to a CUG depend on the result of the validation checks performed
there based on whether the user belongs to one or more CUGs and on the
combination of CUG facilities that applies.
.bp
.RT
.LP
a)
\fICUG call without outgoing access\fR
.LP
If the result of the validation check indicates that the
call should be dealt with as a CUG call, the interlock code of the selected
CUG is obtained. The initial address message forwarded to the next exchange
then
includes the interlock code together with an indication that the call is
a CUG call without outgoing access. The ISUP preference indicator of the
forward call indicators parameter in the IAM is set to \*QISUP required
all the way\*U.
.LP
b)
\fICUG call with outgoing access\fR
.LP
If the result of the validation check indicates that the
call should be dealt with as a CUG call with outgoing access, the interlock
code of the selected CUG together with an outgoing access indication is
obtained. The initial address message forwarded to the next exchange then
includes the interlock code together with an indication that the call is
a CUG call for which outgoing access is allowed. The ISUP preference indicator
of the forward call indicators parameter in the IAM is set to \*QISUP preferred
all the way\*U, unless another service requires a more stringent setting.
.LP
c)
\fINon\(hyCUG call\fR
.LP
If the result of the validation check indicates that the
call should be dealt with as a non\(hyCUG call, the initial address message
forwarded to the next exchange then does not include an interlock code nor a
CUG call indication.
.LP
d)
\fICall rejected\fR
.LP
If the result of the validation check indicates that the
call is to be rejected, the call set\(hyup is not initiated.
.sp 1P
.LP
3.2.2
\fITransit exchange\fR
.sp 9p
.RT
.PP
With the possible exception of some gateway exchanges, each transit exchange
sets up a CUG call as an ordinary call. The information related to the
CUG facilities received from the preceding exchange, i.e.\ an interlock
code, a CUG call indication \(em\ possibly with an indication that outgoing
access is
allowed\ \(em is forwarded to the succeeding exchange.
.PP
In the case of an international CUG call, no special functions are
required at the gateway exchange provided that the international interlock
code assigned to the international CUG concerned is used in the national
network.
However, in the case where a national interlock code other than the applicable
international interlock code is used within a national network, interlock
code conversion is required at the gateway (or corresponding) exchange.
.PP
In case of interworking with a network which does not support the CUG facility,
the gateway exchange may release the call, depending on the contents of
the CUG call indicator in the received IAM. The action at the gateway
exchange, in this case, is indicated in Table\ 1/Q.730. In cases where
a call is rejected as the result of the interworking, a release message
including the
cause parameter indicating ##\ 88 is sent towards the originating exchange.
.RT
.sp 1P
.LP
3.2.3
\fIDestination exchange\fR
.sp 9p
.RT
.PP
At the destination exchange a validation check of the acceptability of
a call is made according to the rule specified in the Recommendation\ Q.85
where either the calling party (as indicated by a CUG call indication in the
initial address message received) or the called party belongs to a CUG. The
call set\(hyup is continued only in cases where the information received checks
with the information stored at the destination exchange. Table\ 2/Q.730
indicates the action to be taken by the destination exchange as the result
of the validation check.
.PP
In cases where a call is rejected as the result of the validation
check because of incompatible CUG information, a release message including
the cause parameter indicating one of the following values is sent towards
the
originating exchange:
.RT
.LP
##55:
Incoming calls barred within CUG
.LP
##87:
Called user not member of CUG
.LP
##88:
Incompatible destination
.PP
Figure 2/Q.730 illustrates example message flows for CUG calls
with decentralized administration of CUG data.
.bp
.sp 1P
.LP
3.3
\fICall set\(hyup procedure with centralized administration\fR
\fIof CUG data\fR
.sp 9p
.RT
.PP
In the local exchange an indication is stored, showing only whether the
user has one or none of the closed user group facilities.
.RT
.sp 1P
.LP
3.3.1
\fIOriginating exchange\fR
.sp 9p
.RT
.PP
The originating exchange requests the CUG validation check to the dedicated
point by invocation of the \*QCUG check\ 1\*U operation through TCAP. This
operation and associated parameters are described in \(sc\ 3.4 of this
Recommendation. The following actions at the originating exchange depend
on the result of this validation check:
.RT
.LP
a)
\fICUG call indication\fR
.LP
If the result of the validation check for the calling user at the originating
exchange indicates that the check for the calling user has been successful,
the interlock code of the selected CUG possibly together with an outgoing
access indication is obtained. The initial address message
forwarded to the next exchange then includes the interlock code together
with an indication that the call is a CUG call without outgoing access
or a CUG call with outgoing access.
.LP
b)
\fINon\(hyCUG call indication\fR
.LP
If the result of the validation check indicates that the
call should be dealt with as a non\(hyCUG call, the initial address message
forwarded to the next exchange then does not include an interlock code nor a
CUG call indication.
.LP
c)
\fICall rejected\fR
.LP
If the result of the validation check indicates that the
call is to be rejected, the call set\(hyup is not initiated.
.sp 1P
.LP
3.3.2
\fITransit exchange\fR
.sp 9p
.RT
.PP
Refer to \(sc 3.2.2.
.RT
.sp 1P
.LP
3.3.3
\fIDestination exchange\fR
.sp 9p
.RT
.PP
In the case of an incoming CUG call for which the validation check for
the calling user has successfully been performed, the received initial
address message includes the interlock code and CUG call indication possibly
with an indication that outgoing access is allowed. The destination exchange
then forwards the information received in the initial address message to the
dedicated point for CUG validation check. In this case, the destination
exchange invokes the \*QCUG check\ 2\*U operation through TCAP. This operation
and associated parameters are defined in \(sc\ 3.4 of this Recommendation.
.RT
.LP
a)
\fICheck successful indication\fR
.LP
If the result of the validation check indicates that the
check has been successful, the index of the CUG selected for the called user
and possibly an outgoing access indication are obtained. The CUG call set\(hyup
request is forwarded to the called user with these indications.
.LP
b)
\fINon\(hyCUG call indication\fR
.LP
If the result of the validation check indicates that the
call should be dealt with as a non\(hyCUG call, the set\(hyup request of
a non\(hyCUG
call is forwarded to the called user.
.LP
c)
\fICall rejected\fR
.LP
If the result of the validation check indicates that the
call is rejected, the reason why the call has been rejected is obtained. A
release message including the cause parameter indicating one of the values
as listed in \(sc\ 3.2.3 is sent towards the originating exchange.
.sp 1P
.LP
3.3.4
\fIDedicated point\fR
.sp 9p
.RT
.PP
At the dedicated point, the CUG validation check is performed
according to the rules defined in Recommendation\ Q.85. The procedures
between the dedicated point and the exchange follow those as defined in
the ASE part of this Recommendation.
.PP
Figure 3/Q.730 illustrates an example message flow for a CUG call with
centralized administration of CUG data.
.bp
.RT
.ce
\fBH.T. [T1.730]\fR
.ce
TABLE\ 1/Q.730
.ce
\fBAction at the gateway with a network without CUG\fR
.ce
.ce
\fBcapability\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(72p) | cw(90p) .
CUG call indicator in IAM {
Action at the gateway exchange
}
_
.T&
lw(72p) | lw(90p) .
CUG without outgoing access {
Release the call with cause ##88
}
_
.T&
lw(72p) | lw(90p) .
CUG with outgoing access {
Treat the call as an ordinary call | ua\d\u)\d
}
_
.T&
lw(72p) | lw(90p) .
Non\(hyCUG Treat the call as an ordinary call
.TE
.LP
\ua\d\u)\d
Discard the interlock code parameter and change the CUG call
indicator of the optional forward call indicator to indicate non\(hyCUG call or
discard the whole parameter if appropriate.
.nr PS 9
.RT
.ad r
\fBTableau 1/Q.730 [T1.730], p. 45\fR
.sp 1P
.RT
.ad b
.RT
.ce
\fBH.T. [T2.730]\fR
.ce
TABLE\ 2/Q.730
.ce
\fBHandling of a CUG call at the destination exchange\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(36p) | cw(42p) | cw(33p) sw(27p) sw(27p) sw(27p) sw(36p) , ^ | ^ | c s | ^ | ^ , ^ | ^ | c | c | c s
^ | ^ | ^ | ^ | c | c | c.
CUG call indicator in IAM CUG match check Class of called user
CUG
No ICB ICB CUG + IA No ICB ICB No CUG
_
.T&
lw(36p) | lw(42p) | lw(33p) | lw(27p) | lw(27p) | lw(27p) | lw(36p) , ^ | l | l s | l | ^ .
CUG with OA not allowed Match CUG call Release cause ##55 CUG call Release cause ##55 {
Release the call with cause ##88
}
No match {
Release the call with cause ##87
} {
Release the call with cause ##87
}
_
.T&
lw(36p) | lw(42p) | lw(33p) | lw(27p) | lw(27p) | lw(27p) | lw(36p) , ^ | l | l s | l | ^ .
CUG with OA allowed Match CUG call Release cause ##55 CUG+OA call Non\(hyCUG call Non\(hyCUG call
No match {
Release the call with cause ##87
} Non\(hyCUG call
_
.T&
lw(36p) | lw(42p) | lw(60p) | lw(54p) | lw(36p) .
Non\(hyCUG \(em {
Release the call with cause ##88
} Non\(hyCUG call Non\(hyCUG call
.TE
.LP
IA
Incoming access
.LP
OA
Outgoing access
.LP
ICB
Incoming calls barred
.LP
Match
The interlock code in the received IAM matches one of the CUGs to
which the called user belongs.
.LP
No match
The interlock code does not match any of the CUGs to which the
called user belongs.
.LP
\fINote\fR
\ \(em\ As OA attribute of the called user is of no concern at the destination exchange, CUG+OA class is equivalent to CUG, and CUG/IA class is equivalent to CUG+IA in this table. Subscription of preferential CUG by the called user is
